Test Results

  182 files  +   30    182 suites  +30   29m 21s ⏱️ + 7m 42s
4 727 tests +   61  4 703 ✅ +   58   24 💤 + 4  0 ❌ ±0 
6 836 runs  +1 182  6 665 ✅ +1 140  171 💤 +43  0 ❌ ±0 

Results for commit 5ce03e5. ± Comparison against base commit 17667a8.

org.eclipse.swt.tests.junit.Test_org_eclipse_swt_widgets_Text ‑ test_backspaceAndDelete

♻️ This comment has been updated with latest results.

I'm surprised the test does not fail in CI. Is UI context really set up there?

Other Mac OS users, could you please run it in your environment to evaluate whether the original problem is specific to my setup?

OS: Mac OS X, v.26.4.1, aarch64 / cocoa
Java vendor: Homebrew
Java runtime version: 25.0.2
Java version: 25.0.2

In any case, this PR is ready to merge.

I suspect that CI is using Java based on an incompatible MacOS SDK and that masks some test failures. There is a major difference in behavior resulting from different SDKs JVM is build against.

With @vogella help, I've managed to reproduce the problem on Mac SDK 14.0 too. It is less severe there, as Display.asyncExec() is not broken, but high CPU usage is still observed. I expect CI to fail now.

The test failures happens on GTK4 CI in addition to expected MacOS. @HeikoKlare could you please check if the test conceptually sound?

Display.readAndDispatch() should almost always return false once UI is drawn and settles. This is normally the case (4 events per second). When the bug is active (Text background color is set) the event rate grows to 122 events per second on fast workstation (or to 60 events per second on a slow one).

I'm not sure what's going on with GTK, if the overall idea is sound, I'll investigate.

The test probably can be simplified by just ensuring that UI thread sleeps for 10 ms at least sometimes.

From eclipse-platform/eclipse.platform.ui#3920 (comment)

@Phillipus #3260 now fails on all SDK versions. It effectively measures CPU load in idle state. I would appreciate your review. Thanks for the help so far.

I refactored the tests into a standalone snippet.

Sometimes the plain Text control (SWT.NONE) passed the tests but other times fails on the 2nd assertion (intensity < 1e-4):

Detected 18/171610 UI event streaks/idle event loop iterations per second, intensity 0.00010. Expected: 2/100_000.

But the Cancel/Search Text control with background color failed both assertions (eventStreakCount < 50 and intensity < 1e-4):

Detected 68/161349 UI event streaks/idle event loop iterations per second, intensity 0.00042. Expected: 2/100_000.

macOS 15.7.5 with Temurin 21 Java.

@basilevs if my commit helps feel free to cherry pick it and push a patch to SWT

Sometimes the plain Text control (SWT.NONE) passed the tests but other times fails on the 2nd assertion (intensity < 1e-4):

Thanks! I saw this instability too, but I've been writing it of as me accidentally moving mouse around. Will keep an eye on it.

@basilevs if my commit helps feel free to cherry pick it and push a patch to SWT

Thanks, maybe later. I'm thinking about GTK4 now. It blinks cursor at 60 Hz refresh rate, breaking my idle assumptions. Disabling blinking for tests does not feel right - it moves the environment further from production.

I think the high cpu load comes from call ((NSSearchField) view).stringValue() in method Text#drawInteriorWithFrame_inView_searchfield. Internally Widget#setNeedsDisplay is called which forces a redraw event. I would say that a method like stringValue() which wants to read the content of a UI widget should not trigger a redraw event.

I think the high cpu load comes from call ((NSSearchField) view).stringValue() in method Text#drawInteriorWithFrame_inView_searchfield. Internally Widget#setNeedsDisplay is called which forces a redraw event. I would say that a method like stringValue() which wants to read the content of a UI widget should not trigger a redraw event.

Unfortunately, this method delegates to MacOS and there is not much that we can do about that:

public NSString stringValue() {
	long result = OS.objc_msgSend(this.id, OS.sel_stringValue);
	return result != 0 ? new NSString(result) : null;
}

Lars Vogel has suggested a fix where the method is not called in the hotspot. That visibly solves the problem.

@squarti please review

I'm not sure what you mean by a feature patch, but it's perfectly acceptable to update the Platform's contribution at any time up until the expect contribution for M3 which should then remain stable. In other words, updates before May 15 are fine and then should remain stable from May 15 through May 21 (when I promote staging).

The changes here are as you say "dramatic" and go deep into the Mac code. From past experience I would be wary of merging this in 4.40. This could have side effects elsewhere that manifest further down the line.

Right now the main impact of this issue manifests on Mac JDKs that have been compiled with Mac SDK 26. So far only the Homebrew JDK is compiled with that. And because the Equinox launcher is compiled with SDK 15 the issue does not manifest in Eclipse itself.

Right now the main impact of this issue manifests on Mac JDKs that have been compiled with Mac SDK 26. So far only the Homebrew JDK is compiled with that. And because the Equinox launcher is compiled with SDK 15 the issue does not manifest in Eclipse itself.

Not true. Elevated CPU use is reproducible on all JDKs and all SDKs.

Not true. Elevated CPU use is reproducible on all JDKs and all SDKs.

I was referring to the problem on dark theme and Text controls not updating. Right now "elevated CPU use" is not a deal breaker. Your proposed changes are, as you say, "dramatic" and are major changes to the Display and Widget classes, not just Text, and could be a deal breaker if there is not enough regression testing.

I'm not sure what you mean by a feature patch, but it's perfectly acceptable to update the Platform's contribution at any time up until the expect contribution for M3 which should then remain stable. In other words, updates before May 15 are fine and then should remain stable from May 15 through May 21 (when I promote staging).

The changes are major, so more manual testing is required before merge. My tests while running PDE from sources are not enough. I have to prepare a patch and install it into daily-driver PDE to look for regressions during daily use.

I did a quick smoke test with this PR with our RCP app and found a major problem. When a text control in a GEF diagram gets the focus the whole background goes blank. That should not happen.

These changes have impact.

And other areas of the UI are not being painted. In the following screen cast the tabbed property items are blank when a new object is selected. They are redrawn when the mouse passes over them:

@basilevs running an aggregator build for the sdk is trivial these days at least under Linux (hence I assume Mac too). Takes only 4 minutes on my machine. Process: clone aggregator, update submodules, get any change you want into the submodule and run the Maven build (skipping tests) with -T6

And I'm seeing editor parts tabs not painted until the mouse hovers over them:

@Phillipus which GEF are you using? Is it FX variant?

@Phillipus which GEF are you using? Is it FX variant?

I use the latest GEF Classic I-build. This has nothing to do with it. Look at this comment and this comment - those are SWT components not GEF.

As I said before the changes in this PR are affecting how the UI is drawn in various places not necessarily related to GEF. And those are the ones I found initially with a quick test, there could be more.

Could not create a feature-patch - getting version conflicts. Every time I need one there are always issues.

Reproduced the CTabFolder blank tab area in debugger, thanks Phillipus.

@basilevs running an aggregator build for the sdk is trivial these days at least under Linux (hence I assume Mac too). Takes only 4 minutes on my machine. Process: clone aggregator, update submodules, get any change you want into the submodule and run the Maven build (skipping tests) with -T6

AFAIK, aggregator needs changes to be already published (works with update sites). Mine are not merged yet.
Also, prexisitng features depend on pre-published plugins, so I see no way to "get a change into the submodule".

No, you can pull in changes from other repos before the build. I do it all the time

No, you can pull in changes from other repos before the build. I do it all the time

I do not have a repo. Even if I had, I would have to somehow override or recreate existing features.

No, you can pull in changes from other repos before the build. I do it all the time

I do not have a repo. Even if I had, I would have to somehow override or recreate existing features.

You have a clone, here is an example how to do that.

 #!/usr/bin/env bash
  set -euo pipefail

  REPO=${1:?repo dir, e.g. eclipse.platform.ui}
  PR=${2:?PR number}

  # 1. update aggregator + submodules
  git pull --rebase
  git submodule update --init --recursive

  # 2. pull the PR into the submodule
  git -C "$REPO" fetch origin "pull/$PR/head:pr-$PR"
  git -C "$REPO" checkout "pr-$PR"

  # 3. build the SDK
  mvn clean verify -Pbuild-individual-bundles -DskipTests

  Usage: ./apply_pr.sh eclipse.platform.ui 2345

I will stop trying to convince you, if you prefer a different way of testing, that is fine for me.

@vogella I think you have a different aggregator in mind, which confused me. I was talking about https://github.com/eclipse-simrel/simrel.build , for which the flow you describe do not seem to apply.

I will re-read contribution guide in an attempt to realign.

I was wondering which wires were crossed because Lars’ advice was sound. You can build the simrel aggregation from the context menu of the .aggr in the Oomphed IDE for simrel. I would show a picture but I’m on my phone.

@vogella I think you have a different aggregator in mind, which confused me. I was talking about https://github.com/eclipse-simrel/simrel.build , for which the flow you describe do not seem to apply.

I will re-read contribution guide in an attempt to realign.

https://github.com/eclipse-platform/eclipse.platform.releng.aggregator

I've built the aggregator by instructions from Lars and the resulting SDK tests fine. I had to install Oomph Targlets separately to make it useful. I'll try it out for a while.

Thanks for all the advice.

I've tested CTabItem rendering in an attempt to prevent the regression found by @Phillipus and got very interesting results on Linux and MacOS GHA. The rendering is broken on some environments, but not on others.